# Understanding the engine

The Nilkins Engine is composed by components. Each of them will provide different functionalities that can be used together or not.

Each component has a position in the ecosystem. It could be represented by something like :

Level 0 | nkLog | nkExport
--- | --- | ---
Level 1 | nkResources | nkTasks | nkMaths | nkMemory
Level 2 | nkInputs | nkScripts | nkWinUi | nkImages
Level 3 | nkGraphics
Level 4 | nkAstraeus

A component higher in the hierarchy can rely on one or more components from the lower levels. For instance, the nkTasks component uses the nkLog component. Or nkScripts uses nkExport, nkLog and nkResources.

For a more detailed description for each of them :

Component | Description | Dependencies
--- | --- | ---
nkLog | Common logging interfaces among the components | -
nkExport | Abstraction over exporting capabilities, such as Json... | -
nkResources | Offers functionnalities to centralize path management | nkLog
nkTasks | Helps with asynchronous work scheduling | nkLog
nkMaths | Offers all needed mathematics functionnalities for the components | nkLog
nkMemory | Offers memory handling capabilities, through pools, pagers... | nkLog
nkInputs | Abstracts input devices and capabilities | nkLog, nkMaths
nkScripts | Allows for scripting environment setup | nkLog, nkExport, nkResources
nkWinUi | Offers ways to create system UIs | nkLog, nkExport, nkResources
nkImages | Offers image formats encoding / decoding capabilities | nkMaths, nkMemory
nkGraphics | Abstracts graphics API usage for graphical work | nkLog, nkExport, nkResources, nkTasks, nkWinUin, nkMemory
nkAstraeus | Leverages all other components to offer higher level access to the engine | nkLog, nkGraphics, nkScripts

# Dependencies

The engine uses some third-party code :

- LuaJIT - To use Lua within nkScripts
- RapidJSON - To parse Json data within nkExport

# General optimizations

The binaries packed into the archive come from the release configuration. While the engine is designed to be usable by any project configuration (debug, release...), some safeties can be disabled to optimize further the client build.

## Devirtualization : NK_ALLOW_DEVIRTUALIZATION

To avoid the compilers taking shortcuts and ignoring exported destructors for virtual classes designed as final, some classes are safe-guarded. Such classes are declared as final using the NK_FINAL keyword. By default, the keyword will hide that a class is final to the client compiler, to avoid any issue.

However, by defining the NK_ALLOW_DEVIRTUALIZATION preprocessor flag in the project settings, it is possible to disable this behaviour to have the classes properly seen as final. This will make the compiler properly take the shortcuts it wants to take.

This flag can generally be activated in any release configuration when using the engine. However, if any crash starts to happen when destructing an object coming from the engine, it means that this flag should not be activated.